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Abstract 

Although  many  algorithms,  hardware  designs,  and  security  pro¬ 
tocols  have  been  formally  verified,  formal  verification  of  the  secu¬ 
rity  of  software  is  still  rare.  This  is  due  in  large  part  to  the  large 
size  of  software,  which  results  in  huge  costs  for  verification.  This 
paper  describes  a  novel  and  practical  approach  to  formally  estab¬ 
lishing  the  security  of  code.  The  approach  begins  with  a  well- 
defined  set  of  security  properties  and,  based  on  the  properties, 
constructs  a  compact  security  model  containing  only  information 
needed  to  reason  about  the  properties.  Our  approach  was  formu¬ 
lated  to  provide  evidence  for  a  Common  Criteria  evaluation  of  an 
embedded  software  system  which  uses  a  separation  kernel  to  en¬ 
force  data  separation.  The  paper  describes  1 )  our  approach  to 
verifying  the  kernel  code  and  2)  the  artifacts  used  in  the  evalua¬ 
tion:  a  Top  Level  Specification  (TLS)  of  the  kernel  behavior,  a  for¬ 
mal  definition  of  data  separation,  a  mechanized  proof  that  the  TLS 
enforces  data  separation,  code  annotated  with  pre-  and  postcon¬ 
ditions  and  partitioned  into  three  categories,  and  a  formal  demon¬ 
stration  that  each  category  of  code  enforces  data  separation.  Also 
presented  is  the  formal  argument  that  the  code  satisfies  the  TLS. 

Categories  and  Subject  Descriptors:  D.2.4  [Software]:  Soft¬ 
ware  Engineering 

General  Terms:  security,  verification,  languages,  theory 

Keywords:  formal  model,  formal  specification,  theorem  proving, 
separation  kernel,  code  verification 

1.  Introduction 

A  critical  objective  of  many  military  systems  is  to  protect  the 
confidentiality  and  integrity  of  sensitive  information.  Preventing 
unauthorized  disclosure  and  modification  of  information  is  of  enor¬ 
mous  importance  in  military  systems,  since  violations  can  jeopar¬ 
dize  national  security.  Compelling  evidence  is  required  therefore 
that  military  systems  satisfy  their  security  requirements. 

A  promising  approach  to  demonstrating  the  security  of  code 
is  formal  verification,  which  has  been  successfully  applied  to  al¬ 
gorithms,  such  as  floating  point  division  [26]  and  clock  synchro- 
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nization  [31],  and  security  protocols  such  as  cryptographic  proto¬ 
cols  [24,  20].  However,  most  past  efforts  to  verify  security-critical 
software  have  been  extremely  expensive.  One  reason  is  that  these 
efforts  often  built  security  models  containing  too  much  detail  (see, 
for  example,  [11])  or  tried  to  prove  too  many  properties  (see,  for 
example,  [36]).  The  result  was  that  model  building  and  property 
proving  became  prohibitively  expensive. 

A  challenging  problem  therefore  is  how  to  make  the  verifica¬ 
tion  of  security-critical  code  affordable.  This  paper  describes  an 
approach  to  verifying  the  security  of  software  that  is  both  novel 
and  practical.  This  approach  was  formulated  in  preparation  for  a 
Common  Criteria  evaluation  of  the  security  of  a  software-based 
embedded  device  called  ED  (Embedded  Device).  For  the  ED  ap¬ 
plication,  satisfying  the  Common  Criteria  required  a  formal  proof 
of  correspondence  between  a  formal  specification  of  ED’s  security 
functions  and  its  required  security  properties  and  a  demonstration 
that  the  code  implementing  ED  satisfied  the  formal  specification. 
ED,  which  processes  data  stored  in  different  partitions  of  mem¬ 
ory,  is  required  to  enforce  a  critical  security  property  called  data 
separation ;  for  example,  ED  must  ensure  that  data  in  one  memory 
partition  neither  influences  nor  is  influenced  by  data  in  another 
partition.  To  ensure  that  data  separation  is  not  violated,  or  if  it  is 
violated  an  exception  occurs,  the  ED  architecture  includes  a  sep¬ 
aration  kernel  [33],  a  tamper-proof,  non-bypassable  program  that 
mediates  every  access  to  memory. 

The  task  of  our  group  was  to  provide  evidence  to  the  certifying 
authority  that  the  ED  separation  kernel  enforces  data  separation. 
The  kernel  code,  which  consists  of  over  3000  lines  of  C  and  as¬ 
sembly  code,  was  annotated  with  pre-and  postconditions  in  the 
style  of  Hoare  and  Floyd.  To  provide  evidence  that  ED  enforces 
data  separation,  we  produced  a  Top  Level  Specification  (TLS)  of 
the  separation-relevant  behavior  of  the  kernel,  a  formal  statement 
of  data  separation,  and  a  mechanized  formal  proof  that  the  TLS 
satisfies  data  separation.  Then,  the  annotated  code  was  partitioned 
into  three  categories,  each  requiring  a  different  proof  strategy.  Fi¬ 
nally,  the  formal  correspondence  between  the  annotated  code  and 
the  TLS  was  established  for  each  category  of  code.  Recently,  five 
artifacts — the  TLS,  the  formal  statement  of  data  separation,  proofs 
that  the  TLS  satisfies  data  separation,  the  organization  of  the  an¬ 
notated  code  into  the  three  categories,  and  the  documents  show¬ 
ing  correspondence  of  each  category  of  code  with  the  TLS — were 
presented  along  with  the  annotated  code  as  evidence  in  a  Common 
Criteria  evaluation  of  ED. 

This  paper  summarizes  the  process  we  followed  in  producing 
evidence  for  the  Common  Criteria  evaluation  of  ED’s  separation 
kernel,  describes  each  artifact  developed  during  this  process,  and 
summarizes  both  the  formal  state  machine  model  that  underlies  the 
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TLS  and  the  formal  argument  justifying  our  approach  to  establish¬ 
ing  code  conformance  with  the  TLS.  The  paper  makes  two  tech¬ 
nical  contributions.  First,  it  describes  a  novel  technique  for  par¬ 
titioning  the  code  into  three  different  categories — namely.  Event, 
Trusted,  and  Other  Code — and  for  reasoning  about  the  security  of 
each  category.  Second,  it  describes  a  method  for  demonstrating  the 
security  of  the  code  that  is  both  original  and  practical.  While  the 
method  combines  a  number  of  well-known  techniques  for  specify¬ 
ing  and  reasoning  about  security — e.g.,  a  state  machine  model  rep¬ 
resented  both  formally  and  in  natural  language,  mechanized  rea¬ 
soning  using  PVS  [34],  and  a  demonstration  of  correspondence  be¬ 
tween  the  TLS  and  the  annotated  source  code — which  techniques 
to  apply,  how  to  apply  them,  and  how  to  combine  them  was  far 
from  obvious  and  required  significant  discussion  during  the  course 
of  the  project.  Along  the  way,  many  alternative  approaches  and 
techniques  were  considered,  and  several  were  discarded.  In  our 
view,  both  the  technique  for  partitioning  the  code  and  the  method 
we  formulated  for  proving  that  the  code  is  secure  should  prove 
useful  in  future  efforts  to  verify  the  security  of  software. 

The  paper  is  organized  as  follows.  Section  2  reviews  the  notion 
of  a  separation  kernel,  summarizes  the  requirements  of  a  Common 
Criteria  evaluation,  and  presents  some  details  of  ED.  Section  3  de¬ 
scribes  the  process  we  followed  to  demonstrate  data  separation  and 
describes  the  five  artifacts  that  the  process  produced,  including  the 
three  categories  of  code  and  how  we  proved  that  each  category  of 
code  is  secure.  Section  4  presents  the  formal  argument  for  demon¬ 
strating  code  conformance.  Sections  5  and  6  discuss  some  lessons 
learned  and  describe  topics  requiring  more  research,  i.e.,  the  need 
for  more  powerful  tool  support.  Section  7  describes  related  work. 
Finally,  Section  8  presents  some  conclusions. 

2.  Background 

2.1  Separation  Kernel 

A  separation  kernel  [33]  mimics  the  separation  of  a  system 
into  a  set  of  independent  virtual  machines  by  dividing  the  mem¬ 
ory  into  partitions  and  restricting  the  flow  of  information  between 
those  partitions.  Separation  kernels  are  being  developed  for  mili¬ 
tary  applications  requiring  Multiple  Independent  Levels  of  Secu¬ 
rity  (MILS)  by  commercial  companies  such  as  Wind  River  Sys¬ 
tems,  Green  Hills  Software,  and  Lynux Works  [4],  In  a  MILS  en¬ 
vironment,  a  separation  kernel  acts  as  a  reference  monitor  [6],  i.e., 
is  non-bypassable,  evaluatable,  always  invoked,  and  tamper  proof. 

2.2  Common  Criteria 

Seven  international  organizations  established  the  Common  Cri¬ 
teria  to  provide  a  single  basis  for  evaluating  the  security  of  infor¬ 
mation  technology  products  [3],  Associated  with  the  Common 
Criteria  are  seven  Evaluation  Assurance  Levels.  EAL7,  the  high¬ 
est  assurance  level,  requires  a  formal  specification  of  a  product’s 
security  functions  and  its  security  model,  and  formal  proof  of  cor¬ 
respondence  between  the  two. 

2.3  Embedded  Device  (ED) 

The  device  of  interest  in  this  paper,  ED,  processes  data  in  an 
embedded  system.  While  at  any  given  time  the  data  stored  and 
processed  by  ED  in  one  memory  partition  is  classified  at  a  single 
security  level,  ED  may  later  reconfigure  that  partition  to  store  and 
process  data  at  a  different  security  level.  Because  it  stores  and 
processes  data  classified  at  different  security  levels,  security  viola¬ 
tions  by  ED  could  cause  significant  damage.  To  prevent  violations 


of  data  separation,  e.g..  the  “leaking”  of  data  from  one  memory 
partition  to  another,  the  ED  design  uses  a  separation  kernel  to  me¬ 
diate  access  to  memory.  By  mediating  every  access,  the  kernel  en¬ 
sures  that  every  memory  access  is  authorized  and  that  every  trans¬ 
fer  of  data  from  one  ED  memory  location  to  another  is  authorized. 
Any  attempted  memory  access  by  ED  that  is  unauthorized  will 
cause  an  exception.  Section  3.3  describes  how  TAME  [8,  7],  an 
interface  to  SRI's  theorem  prover  PVS  [34],  was  used  to  support 
the  Common  Criteria  evaluation  of  ED’s  separation  kernel. 

3.  Code  Verification  Process 

The  process  followed  in  constructing  the  five  ED  artifacts  con¬ 
sists  of  five  steps.  The  process  described  below  is  an  idealiza¬ 
tion  of  the  actual  process  since,  in  any  real-world  process,  one 
frequently  returns  to  a  former  step  to  make  corrections  and  add 
missing  information.  However,  the  sequence  of  steps  that  follows 
is  a  logical  order  for  producing  the  various  artifacts. 

1 .  Formulate  a  Top  Level  Specification  (TLS)  of  the  kernel  as  a 
state  machine  model,  using  the  style  introduced  in  [21,  23]. 

2.  Formally  express  the  data  separation  property  in  terms  of 
the  inputs,  state  variables,  and  transitions  defined  in  the  state 
machine  model  that  underlies  the  TLS. 

3.  Translate  the  TLS  and  the  data  separation  property  into  the 
language  of  a  mechanical  prover,  and  prove  formally  that 
the  TLS  satisfies  the  data  separation  property. 

4.  Given  a  source  code  implementation  of  the  kernel  annotated 
with  pre-  and  postconditions,  partition  the  code  into  Event, 
Other,  and  Trusted  Code,  where,  informally.  Event  Code  is 
code  corresponding  to  an  event  in  the  TLS  that  touches  a 
Memory  Area  of  Interest  (defined  below),  Trusted  Code  is 
code  that  touches  a  Memory  Area  of  Interest  but  is  not  Event 
Code,  and  Other  Code  is  neither  Event  Code  nor  Trusted 
Code,  Section  3.4  provides  precise  definitions  of  the  three 
different  code  categories. 

5.  Demonstrate  that  the  Event  Code  does  not  violate  separation 
by  constructing  1)  a  mapping  from  the  Event  Code  to  the 
TLS  events  and  from  the  code  states  to  the  states  in  the  TLS, 
and  2)  a  mapping  from  pre-  and  postconditions  of  the  TLS 
events  to  pre-  and  postconditions  that  annotate  the  corre¬ 
sponding  Event  Code.  Demonstrate  separately  that  Trusted 
Code  and  Other  Code  do  not  violate  data  separation. 

3.1  Top  Level  Specification 

Major  goals  of  the  Top  Level  Specification  (TLS)  are  to  pro¬ 
vide  a  precise,  yet  understandable  description  of  the  required  ex¬ 
ternal  behavior  of  ED’s  separation  kernel  and  to  make  explicit  the 
assumptions  on  which  the  specification  is  based.  To  achieve  this, 
the  TLS  represents  the  kernel  as  a  state  machine  model  using  pre¬ 
cise  natural  language.  Such  a  natural  language  description  was 
introduced  in  1984  to  describe  the  behavior  of  a  secure  military 
message  system  (MMS)  [21,  23].  The  advantage  of  natural  lan¬ 
guage  is  that  it  enables  stakeholders  from  differing  backgrounds 
and  with  different  objectives — the  project  manager,  software  de¬ 
velopers,  evaluators,  and  formal  methods  team — to  communicate 
precisely  about  the  required  kernel  behavior  and  helps  ensure  that 
misunderstandings  are  weeded  out  and  issues  resolved  early  in  the 
verification  process.  Another  goal  of  the  TLS  is  to  provide  a  for¬ 
mal  context  and  precise  vocabulary  for  defining  data  separation. 


Like  the  secure  MMS  model,  the  state  machine  representing  the 
behavior  of  the  ED  kernel  is  defined  in  terms  of  an  input  alphabet, 
a  set  of  states,  an  initial  state,  and  a  transform  relation  describing 
the  allowed  state  transitions.  The  input  alphabet  contains  internal 
and  external  events,  where  an  internal  event  can  cause  the  kernel 
to  invoke  some  process  and  an  external  event  is  performed  by  an 
external  host.  An  example  of  an  internal  event  is  an  event  instruct¬ 
ing  ED  to  copy  data  from  an  input  buffer  associated  with  memory 
partition  i  to  a  data  area  in  partition  i.  An  example  of  an  external 
event  is  the  event  occurring  when  an  external  host  writes  data  into 
an  input  buffer  assigned  to  partition  i.  The  transform  (also  called 
the  next- state  relation)  is  defined  on  triples  consisting  of  an  event 
in  the  input  alphabet,  the  current  state,  and  the  new  state.  Provided 
below  are  excerpts  from  the  TLS  as  well  as  an  example  internal 
event.  This  event,  Copy_Buf  Hn_DatalIn_?',  copies  data  from  an 
input  buffer  for  partition  i  into  a  data  area  in  partition  i. 

Partitions,  State  Variables,  Events  and  States.  We  assume  the 
existence  of  n  >  1  dedicated  memory  partitions  and  a  single 
shared  memory  area.  We  also  assume  the  existence  of  the  fol¬ 
lowing  sets: 

•  V  is  a  union  of  types,  where  each  type  is  a  non-empty  set  of 
values. 

•  R  is  a  set  of  state  variable  names.  For  all  r  in  R,  TY (r)  C 
V  is  the  set  of  possible  values  of  state  variable  r.  Ai  is 
a  union  of  N  non-overlapping  memory  areas,  each  repre¬ 
sented  by  a  state  variable. 

•  H  =  P  U  E  is  a  set  of  M  events,  where  each  event  is  either 
an  internal  event  in  P  or  an  external  event  in  E. 

A  system  state  is  a  function  mapping  each  state  variable  name  r  in 
R  to  a  value.  Formally,  for  all  r  £  R:  s(r)  £  TY (r). 

Memory  Areas.  The  N  memory  areas  contain  N  —  1  Memory 
Areas  of  Interest,  where  N  —  1  =  mn ,  and  m  is  the  number  of 
Memory  Areas  of  Interest  per  partition.  Informally,  a  Memory 
Area  of  Interest  (MAI)  is  a  memory  area  containing  data  whose 
leakage  would  violate  data  separation.  The  m  MAIs  for  a  parti¬ 
tion  i,  1  <  i  <  n,  include  partition  i’s  input  and  output  buffers 
and  k  data  areas  where  data  in  partition  i  is  stored  and  processed. 
The  TVth  memory  area,  called  G,  contains  all  programs  and  data 
not  residing  in  an  MAI  and  is  the  single  shared  memory  area.  The 
set  Ai  of  all  memory  areas  is  defined  as  the  union  A  U  {  G} ,  where 
A  =  {Aij  \  1  <  i  <  n  A  1  <  j  <  m}  contains  the  mn  MAIs. 
For  all  i,  1  <  i  <  n,  A,  =  {Aij  |  1  <  j  <  m}  is  the  set  of 
memory  areas  for  partition  i.  To  guarantee  that  the  memory  areas 
of  Ai  are  non-overlapping,  the  memory  areas  are  required  to  be 
pairwise  disjoint. 

State  Variables.  The  set  of  state  variables1  contained  in  R  are 

•  a  partition  id  c, 

•  the  N  memory  areas  in  Ai ,  and 

•  a  set  of  n  sanitization  vectors  Wd  [1], . . .,  WD[n],  each  vec¬ 
tor  containing  k  elements. 

1By  convention,  state  variable  names  may  refer  to  the  values  of 
the  variables. 


The  partition  id  c  is  0  if  no  data  processing  in  any  partition  is  in 
progress,  and  *,  1  <  i  <  n,  if  data  processing  is  in  progress  in 
partition  i.  (Data  processing  can  occur  in  only  one  partition  at  a 
time.)  For  1  <  j  <  k,  the  boolean  value  of  the  jth  element  WJ  [i] 
of  the  sanitization  vector  for  partition  i  is  true  if  the  jth  memory 
area  of  the  ?'th  partition  has  been  sanitized  and  false  otherwise.  A 
sanitized  memory  area  is  modeled  as  having  the  value  0. 

Events.  The  set  of  internal  events  P  C  H  is  the  union  of  n  sets, 
P] ,  P„ ,  of  partition  events ,  one  set  for  each  partition  i,  and  a 
singleton  set  Q;  thus  P  is  defined  by  P  =  [U"=1  P,]  U  Q.  Process¬ 
ing  occurs  on  partition  i  when  a  sequence  of  events  from  Pi  is  pro¬ 
cessed.  The  sole  member  of  Q  is  the  event  Other_NonParProc, 
an  abstract  internal  event  representing  all  internal  events  which 
invoke  data  processing  in  the  shared  message  area  G.  One  exam¬ 
ple  of  such  an  event  is  Assign_Val,  which  causes  some  value  to 
be  stored  in  G.  The  set  of  external  events  E  C  H  is  defined  by 
E  =  Eln\JE°ut  U  {Ext  _Ev_0ther } ,  where  Eln  =  U "=1£{n  and 
E°nt  _  u ?=1E°ut.  E\"  is  the  set  of  external  events  writing  into 
or  clearing  the  input  buffers  assigned  to  partition  i,  and  £lPut  is  the 
set  of  external  events  reading  front  or  clearing  the  output  buffers 
assigned  to  partition  i.  The  event  Ext_Ev_0ther  represents  all 
other  external  events. 

Partition  Functions.  Operations  on  data  in  partition  i,  for  ex¬ 
ample,  an  operation  copying  data  from  one  MAI  in  partition  i 
to  another  MAI  in  i,  are  called  ‘partition  functions.'  For  all  i, 
1  <  i  <  n,  and  for  each  internal  event  e  in  Pi,  there  exists  a  par¬ 
tition  function  Te  associated  with  e.  Each  function  Te  computes 
a  value  stored  in  an  MAI  in  A.  For  all  e  £  P,  ,  Te  has  the  signa¬ 
ture  Te  :  TY(oi)  — >  TY(a2),  where  ai  and  a 2  are  MAIs  in  At. 
Thus,  each  function  Te,  where  e  is  an  internal  event  in  Pi,  takes  a 
single  argument,  the  value  stored  in  some  MAI  01,  and  uses  that 
argument  to  compute  a  value  to  be  stored  in  MAI  «2 . 

Access  Control  Matrix.  Associated  with  the  M  events  and  the 
N  memory  areas  is  an  M  by  N  access  control  matrix  AM,  which 
indicates  the  read  and  write  access  that  each  internal  event  e  in  P 
(and  its  associated  process)  and  each  external  event  e  in  H  has  for 
each  memory  area  a  in  Ai .  Each  entry  in  the  matrix  is  either  null 
meaning  no  access,  R  for  read  access,  W  for  write  access,  or  RW  for 
both  read  and  write  access.  The  left-most  column  of  AM  lists  the 
events  in  H,  and  the  headings  of  the  remaining  columns  list  the  N 
memory  areas  in  Ai  as  well  as  G. 

For  all  i,j,  1  <  i,j  <  n,  i  ^  j,  an  event  associated  with  par¬ 
tition  i  has  null  access  to  an  MAI  associated  with  partition  j  or 
to  G;  similarly,  an  event  associated  with  j  has  null  access  to  an 
MAI  associated  with  i  or  to  G.  Moreover,  the  single  event  that  in¬ 
vokes  non-partition  processing,  namely,  Other_NonParProc,  has 
R  and  W  access  for  G  and  access  null  for  all  other  memory  areas, 
i.e.,  the  MAIs.  Finally,  the  external  events  associated  with  parti¬ 
tion  i  can  only  write  into  or  read  from  input  and  output  buffers 
associated  with  i. 

System.  A  system  is  a  state  machine  whose  transitions  from  one 
state  to  the  next  are  triggered  by  events.  Formally,  a  system  S  is  a 
4-tuple  S  =  (H,  S,so,T),  where 

•  H  is  the  set  of  events, 

•  S  is  the  set  of  states, 

•  so  is  the  initial  state,  and 


•  T  is  the  system  transform,  a  partial  function  from  H  x  S 
into  S.  T  is  partial  because  not  all  events  are  ‘enabled’  to 
be  executed  in  the  current  state. 

Initial  State.  In  the  initial  state  so.  the  partition  id  c  is  0;  for  all  i, 
1  <  i  <  n,  the  MAIs  in  A;  are  0;  and  each  element  of  the  sanitiza¬ 
tion  vectors,  Wd[1]  ■  •  •  Wo  [n] ,  is  true.  Hence,  in  the  initial  state, 
no  processing  in  any  partition  is  authorized,  only  a  non-partition 
process  is  authorized  to  execute,  each  element  of  every  sanitization 
vector  has  the  value  true,  and  all  MAIs  have  the  value  zero. 

System  Transform.  The  transform  T  is  defined  in  terms  of  a  set 
1Z  of  transform  rules,  7Z  =  {  7Ze  \  e  £  H  },  where  each  transform 
rule  7 Ze  describes  how  an  event  e  transforms  a  current  state  into  a 
new  state.  The  number  of  rules  is  M,  one  rule  for  each  of  the  M 
events  in  H.  No  rule  requires  access  privileges  other  than  those 
defined  by  the  access  control  matrix  AM.  The  notation  s  and  s' 
represents  the  current  state  and  the  new  state.  Given  state  s  and 
state  variable  r,  r’s  value  in  s  is  denoted  by  rs.  When  an  internal 
or  external  event  e  does  not  affect  the  value  of  any  state  variable  r, 
when  the  precondition  is  not  satisfied,  or  when  the  event  e  is  not 
enabled,  the  value  of  r  does  not  change  from  state  s  to  state  s',  and 
the  state  variable  r  retains  its  current  value,  i.e.,  r3  =  r3i. 

To  denote  that  no  state  variable  except  those  explicitly  named 
changes,  we  write  NOC;;  (NO  Change  except  to  variables  in  R), 
where  R  C  R.  This  includes  the  case  where  the  ith  element  of  a 
sanitization  vector  changes  but  no  other  vector  elements  change. 
For  example,  the  postcondition  r3>  =  x  A  NOC{r},  where  x  £ 
TY (r),  is  equivalent  to  r3>  =  x  A  V  r  £  R,  r  ^  r  :  rsi  =  r3. 

Suppose  s  is  a  state  in  S,  e  is  an  event  in  H,  and  R  is  the  set 
of  state  variables.  Let  pree  be  a  state  predicate  associated  with 
e  such  that  pree  evaluates  to  true  if  e  has  the  potential  to  occur 
in  state  s  and  and  false  otherwise,  and  let  poste  be  a  predicate 
associated  with  e  such  that  poste(s,  s')  holds  whenever  e  occurs 
in  state  s  and  s'  is  a  possible  poststate  of  s  when  event  e  occurs  in 
state  s.  Formally,  the  transform  rule  7Ze  in  7 Z  is  defined  by 

7 Ze  ■■  pree(s)  =>■  poste(s,  s'). 

Whenever  the  result  state  of  every  event  e  is  deterministic  (which 
is  true  in  the  TLS),  the  assertion  poste(s,  s')  defines  the  poststate 
s'  =  T(e,  s).  To  make  T  total  on  H  x  S,  the  complete  definition 
of  T  is  written  as 

rlp  =  f  s'  if  Pree(s)>  where poste(s, s') 

’  '  s  otherwise. 

In  the  above  definition,  pree  ( s )  is  not  satisfied  implies  that  e  has 
no  effect — i.e.,  essentially,  did  not  occur. 

Example  of  a  Transform  Rule.  Consider  an  internal  event,  e  = 
Copy_Bf rlIn_DatalInJ,  which  invokes  a  process  copying  data 
from  partition  i’s  Input  Buffer  1,  denoted  B],  into  partition  i’s 
Data  Area  1,  denoted  D j.  The  transform  rule  for  e  is  denoted 
7^-copy_Bf riin_Dataiin_i  •  Preconditions  for  e  are  (1)  the  partition  id  c 
equals  i,  and  (2)  the  invoked  process  must  have  read  access  (‘R’) 
for  partition  i’s  Input  Buffer  1  and  write  access  (‘W’)  for  Data 
Area  1  in  i.  Postconditions  for  e  are  that  (3)  the  element  for  Data 
Area  1  in  i’s  sanitization  vector  becomes  false,  (4)  a  function  of 
the  value  stored  in  i’s  Input  Buffer  1  is  written  into  i’s  Data  Area  1, 
and  (5)  no  other  state  variable  changes.  For  all  i,  the  rule  TZe  for 
event  e  =  Copy_Bf  rlIn_DatalIn_i  is  defined  by 


7?-Copy_Bf rlIn_DatalIn_i  • 

cs  =i  A  (1) 

AM[e,  ai]  =  R  and  AM[e,  02]  =  W  (2) 

where  ai  =  B,1  and  02  =  D] 

=>  wh, s’ [i\=  false  A  (3) 

D\y  =  r  e(Bls)  A  (4) 

(5) 

3.2  Security  Policy:  Data  Separation 


To  operate  securely,  ED  must  enforce  data  separation.  Infor¬ 
mally,  this  means  that  ED  must  prevent  data  in  a  partition  i  from 
influencing  or  being  influenced  by  1)  data  in  a  partition  j,  where 

1  j,  2)  an  earlier  configuration  of  partition  i,  or  3)  data  stored 
in  G.  Thus  ED  must  prevent  non-secure  data  flows.  To  demon¬ 
strate  that  the  TLS  enforces  data  separation,  we  proved  that  it  sat¬ 
isfies  five  subproperties,  namely,  No-Exfiltration,  No-Infiltration, 
Temporal  Separation,  Separation  of  Control,  and  Kernel  Integrity. 
Below,  each  subproperty  is  defined  formally  using  the  notation  in¬ 
troduced  in  Section  3.1. 

3.2.1  No-Exfiltration  Property 

The  No-Exfiltration  Property  states  that  data  processing  in  any 
partition  j  cannot  influence  data  stored  outside  the  partition.  This 
property  is  defined  in  terms  of  the  set  Aj  (the  MAIs  of  partition  j); 
the  entire  memory  M ;  the  internal  events  in  Pj,  which  invoke  data 
processing  in  j\  and  external  events  in  B]n  U  Ej>ut,  which  affect 
data  in  j’s  input  and  output  buffers. 

Property  3.1  (No-Exfiltration)  Suppose  that  states  s  and  s'  are  in 
state  set  S,  event  e  is  in  H,  memory  area  a  is  in  M,  and  j  is  a 
partition  id,  1  <  j <  n.  Suppose  further  that  s'  =  T(e,  s).  Ife  is 
an  event  in  Pj  U  Bjn  U  B®ut  and  aa  as /,  then  a  is  in  Aj. 

3.2.2  No-Infiltration  Property 

The  No-Infiltration  Property  states  that  data  processing  in  any 
partition  i  is  not  influenced  by  data  outside  that  partition.  It  is  de¬ 
fined  in  terms  of  the  set  A;,  which  contains  the  MAIs  of  partition  i. 

Property  3.2  (No-Infiltration)  Suppose  that  states  s  1,  S2,  si,  and 
s'2  are  in  S,  event  e  is  in  H,  and  i  is  a  partition  id,  1  <  i  <  n. 
Suppose  further  that  s'i  =  T(e,s  1)  and  s'2  =  T{e,s2).  If  for  all 
a  in  Ait  asi  =  aS2,  then  for  all  a  in  Ait  as  =  a3>o. 

3.2.3  Temporal  Separation  Property 

The  objective  of  this  property  is  to  guarantee  that  the  k  data 
areas  in  any  partition  i  are  clear  when  the  system  is  not  processing 
data  in  that  partition,  e.g.,  from  the  end  of  a  processing  thread  in 
one  partition  to  the  start  of  a  new  processing  thread  in  the  same 
or  a  different  partition.2  Satisfying  this  property  implies  a  second 
property — i.e.,  no  data  (e.g.,  Top  Secret  data)  in  a  partition  during 
one  configuration  of  the  ith  partition  can  leak  into  a  later  configu¬ 
ration  (e.g.,  at  the  Unclassified  level)  of  the  same  partition  i.  The 
set  of  states  in  which  the  system  is  not  processing  data  stored  in  a 
partition  is  exactly  the  set  of  states  in  which  the  partition  id  c3  is  0. 
This  fact  can  be  used  in  stating  the  Temporal  Separation  Property. 

2  The  proof  of  this  property  depends  on  a  constraint  imposed  by 
the  transform  rules  on  the  partition  id  c:  If  c  changes,  it  changes 
from  0  to  non-zero  or  vice  versa. 


Property  3.3  (Temporal  Separation)  For  all  states  s  in  S,  for  all  i, 
1  <  i  <  n,  if  the  partition  id  cs  is  0,  then  the  k  data  areas  of 
partition  i  are  clear,  i.e.,  D}  s  =  0,  . .  Df  s  =  0. 

3. 2. 4  Separation  of  Control  Property 

This  property  states  that  when  data  processing  is  in  progress 
on  partition  i,  no  data  is  being  processed  on  partition  j,  j  f  i, 
until  processing  on  partition  i  terminates.  The  property  is  defined 
in  terms  of  the  partition  id  c,  which  is  i  if  processing  is  in  progress 
on  partition  i,  where  i  >  0,  and  0  otherwise,  and  the  set  Di  of  k 
data  areas  in  partition  i,  Dt  =  { D \  |  1  <  j  <  k}. 

Property  3.4  (Separation  of  Control)  Suppose  that  states  s  and 
s'  are  in  S,  event  e  is  in  H,  data  area  a  is  in  M,  and  j,  where 
1  <  j  <  n,  is  a  partition  id.  Suppose  further  that  s'  =  T(e,  s).  If 
neither  cs  nor  csi  is  j,  then  as  =  asr  for  all  a  £  Dj. 

3.2.5  Kernel  Integri ty  Property 

The  Kernel  Integrity  Property  states  that  when  data  processing 
is  in  progress  on  partition  i,  the  data  stored  on  memory  area  G 
does  not  change.  This  property  is  defined  in  terms  of  G  and  the  set 
Pi  of  events  for  partition  i. 

Property  3.5  (Kernel  Integrity)  Suppose  that  states  s  and  s'  are 
in  state  set  S,  event  e  is  in  H,  and  i  is  a  partition  id,  1  <  i  <  n. 
Suppose  further  that  s'  =  T(e,  s).  If  e  is  a  partition  event  in  Pi, 
then  Gs /  =  Gs. 

3.3  Formal  Verification 

To  formally  verify  that  the  TLS  enforces  data  separation,  the 
natural  language  formulation  of  the  TLS  was  translated  into  TAME 
(Timed  Automata  Modeling  Environment)  [8,  7],  a  front-end  to 
the  mechanical  prover  PVS  [27]  which  helps  a  user  specify  and 
reason  formally  about  automata  models.  This  translation  requires 
the  completion  of  a  template  to  define  the  initial  states,  state  tran¬ 
sitions,  input  events,  and  other  attributes  of  the  state  machine  E. 
The  TAME  specification  provides  a  machine  version  of  the  TLS 
that  can  be  shown  mechanically  to  satisfy  the  five  subproperties 
defined  above. 

After  constructing  the  TAME  specification  of  the  TLS,  we  for¬ 
mulated  two  sets  of  TLS  properties  in  TAME — invariant  prop¬ 
erties  and  other  properties — that  together  formalize  the  five  sub¬ 
properties.  Then,  for  each  set  of  properties,  we  interactively  con¬ 
structed  (TAME)  proofs  showing  that  the  TAME  specification  sat¬ 
isfies  each  property.  The  scripts  of  these  proofs,  which  are  saved 
by  PVS,  can  be  rerun  easily  by  the  evaluators  and  serve  as  the  for¬ 
mal  proofs  of  data  separation.  One  benefit  of  TAME  is  that  the 
saved  PVS  proof  scripts  can  be  largely  understood  without  rerun¬ 
ning  them  in  PVS. 

3.4  Partitioning  the  Code 

To  show  formally  that  the  ED  separation  kernel  enforces  data 
separation,  we  must  prove  that  the  kernel  is  a  secure  partial  in¬ 
stantiation  of  the  state  machine  E  defined  by  the  TLS.  The  for¬ 
mal  verification  described  in  Section  3.3  establishes  formally  that 
a  strict  instantiation  of  the  TLS  enforces  data  separation.  A  par¬ 
tial  instantiation  of  the  TLS  is  an  implementation  that  contains 
fine-grain  details  which  do  not  correspond  to  the  state  machine  E 
defined  in  the  TLS.  A  secure  partied  instantiation  of  the  TLS  is  a 
partial  instantiation  of  the  TLS  in  which  the  fine-grain  details  that 
do  not  correspond  to  the  TLS  are  benign.  Section  4  contains  the 


formal  foundation  for  the  proof  that  the  code  is  a  secure  partial 
instantiation  of  the  TLS. 

The  proof  that  the  code  for  the  ED  kernel  is  a  secure  partial 
instantiation  of  the  TLS  is  based  on  a  demonstration  that  all  kernel 
code  falls  into  three  major  categories  and  one  subcategory,  with 
proofs  that  the  code  in  each  category  satisfies  certain  properties. 
The  categories  are  as  follows: 

1 .  Event  Code  is  kernel  code  which  implements  a  TLS  inter¬ 
nal  event  e  in  H  and  touches  one  or  more  MAIs.  For  each 
segment  of  Event  Code,  it  is  checked  that 

(i)  the  concrete  translation  of  the  precondition  in  the  TLS 
for  the  corresponding  event  e  is  satisfied  at  the  point  in 
the  kernel  code  where  the  execution  of  the  Event  Code 
is  initiated,  and 

(ii)  the  concrete  translation  of  the  postcondition  in  the  TLS 
for  the  corresponding  event  e  is  satisfied  at  the  conclu¬ 
sion  of  Event  Code  execution. 

2.  Trusted  Code  is  kernel  code  which  touches  MAIs  but  is  not 
Event  Code.  This  code  does  not  correspond  to  behavior  de¬ 
fined  by  the  TLS  and  may  have  read  and  write  access  both 
to  MAIs  and  to  memory  areas  outside  of  the  MAIs.  It  is 
validated  either  by  a  proof  that  the  code  does  not  permit  any 
non-secure  information  flows  or,  in  rare  instances,  by  as¬ 
sumption.  The  TLS  makes  explicit  any  assumptions  used  in 
connection  with  Trusted  Code  and  its  behavior.  The  proofs 
for  a  given  segment  of  Trusted  Code  characterize  the  en¬ 
tire  functional  behavior  of  that  Trusted  Code  using  Floyd- 
Hoare  style  assertions  at  the  code  level  and  show  that  no 
non-secure  information  flows  can  occur  in  that  code. 

3.  Other  Code  is  kernel  code  that  is  neither  Event  nor  Trusted 
Code.  More  specifically,  Other  Code  is  kernel  code  which 
does  not  correspond  to  any  behavior  defined  by  the  TLS  and 
which  has  no  access  to  any  MAIs.  Apple’s  Xcode  develop¬ 
ment  tool  [2]  was  used  to  search  the  kernel  code  to  locate  all 
code  segments  with  access  to  MAIs,  i.e,  code  segments  clas¬ 
sified  as  Event  or  Trusted  Code.  This  involved  identifying 
all  places  in  the  kernel  code  where  the  MMU  is  reset  and 
observing  the  permissions  assigned.  By  observing  the  ac¬ 
cess  granted  for  code  segments  categorized  as  Other  Code, 
we  can  ensure  that  they  have  no  access  to  any  MAI. 

(a)  A  subset  of  Other  Code,  called  Verified  Code,  is  code 
with  no  access  to  MAIs  which  is  still  security-relevant 
because  it  performs  functions  necessary  for  the  kernel 
to  enforce  data  separation.  These  functions  include 
setting  up  the  MMU,  establishing  preconditions  for 
Event  Code,  etc.  Floyd-Hoare  style  assertions  at  the 
code  level  are  used  to  prove  that  Verified  Code  cor¬ 
rectly  implements  the  required  functions. 

3.5  Demonstrating  Code  Conformance 

Demonstrating  code  conformance  requires  the  definition  of  two 
mappings.  To  establish  correspondence  between  concrete  states 
in  the  kernel  code  and  abstract  states  in  the  TLS,  a  function  a  is 
defined  that  relates  concrete  states  to  abstract  states  by  relating 
concrete  entities  (such  as  memory  areas,  code  variables,  and  log¬ 
ical  variables)  at  the  code  level  to  abstract  state  variables  (such 
as  MAIs  and  the  partition  id)  in  the  TLS.  For  example,  the  actual 
physical  addresses  of  the  MAIs  are  mapped  to  their  corresponding 


{CopyDIn_partition_id  :  partition  =  partition-id} 

{CopyDIn_priv  : 

{(R,KER_INBUFFER_l_partition),  (W,  KER_PAR_DATA_STORAGE_l_partition)}  C  MMU} 
{CopyDIn_value_data  :  Vj.O  <  j  <  byte.length. 

A[j]  =  KER_INBUFFER_1  _part  it  ion_START  +  j} 

{CopyDIn_def  _value_rest  :  Vj  .byte.length  <  j  <  KER_PAR_DATA_STORAGE_l_partition_SIZE. 

B[j]  =  KER_PAR_DATA_STORAGE_l_partition_START  +  j} 

{CopyDIn_local_inbuff  er  :  buf  f  er_in_start  =  KER_INBUFFER_l_partition_START} 
{CopyDIn_local_datain  :  part_data_start  =  KER_PAR_DATA_STORAGE_l_partition_START} 


if  (byte_length  <  (unsigned  long) & _ INBUFFER_SIZE) 

{ 

/*  copy  data  from  inbuffer  1  to  partition  */ 

/*  part_data_start  contains  the  starting  address  of  */ 

/*  the  memory  area,  buf fer_in_start  contains  */ 

/*  the  starting  address  of  the  inbuffer  */ 

/*  kerne l_memcopy  is  a  copy  routine  whose  functional  correctness  */ 
/*  has  been  verified  using  Floyd-Hoare  assertions  */ 
kernel_memcopy (part_data_start ,  buf fer_in_start ,  byte_length) ; 

} 

{CopyDIn_copy_size_datain  :  byte_length  >  KER_PAR_DATA_STORAGE_partition_SIZE  — >  false} 
{CopyDIn_copy_size_inbuf f er  :  byteJLength  >  KER_INBUFFER_l_partition_SIZE  — >  false} 
{CopyDIn_gamma_copy  :  Vj.O  <  j  <  byte.length. 

KER_PAR_DATA_STORAGE_l_partition_START  +  j  =  A[j]} 

{CopyDIn_gamma_rest  :  Vj  .byte_length  <  j  <  KER_PAR_DATA_STORAGE_l_partition_SIZE. 

KER_PAR_DATA_STORAGE_l_partition_START  +  j  =  B[j]} 

{CopyDIn_sanitize  :  part_data_sanitized_partition  =  false} 

{CopyDIn_NOC  :  No  concrete  state  variables  have  changed  value  except  possibly 
KER_PAR_DATA_STORAGE_partition  and  part_data_sanitized_partition.  } 


Figure  1.  Event  Code  and  Code  Level  Assertions  for  Event  Copy_Bfrlln_Datalln_i 


abstract  state  variables  in  the  TLS.  The  map  a  also  maps  Event 
Code  to  events  in  the  TLS.  Another  map  $  relates  assertions  at  the 
abstract  TLS  level  to  assertions  at  the  code  level  derived  from  the 
map  a.  See  Section  4  for  more  details. 

Using  <f>  to  relate  pre-  and  postconditions  for  an  event  in  the 
TLS  to  derived  pre-  and  postconditions  for  the  corresponding  Event 
Code,  we  next  determine  for  each  piece  of  Event  Code  sets  of 
code-level  pre-  and  postconditions  that  match  the  derived  pre-  and 
postconditions  as  closely  as  possible.  Figure  1  shows  the  Event 
Code  corresponding  to  the  Copy_Bf  rlIn_DatalIn_i  event  in  the 
TLS  and  the  code  level  pre-  and  postconditions  for  this  Event 
Code.  In  Figure  1,  the  top  box  contains  the  preconditions,  then 
the  indented  Event  Code  is  listed,  and  finally  the  bottom  box  con¬ 
tains  the  postconditions;  each  pre-  and  postcondition  has  the  form 
{AssertionJJame  :  Assertion}.  Generally,  the  match  between 
assertions  in  the  TLS  and  derived  code-level  assertions  is  not  exact 
because  auxiliary  assertions  are  added  1)  to  express  the  correspon¬ 
dence  between  variables  in  the  code  and  physical  memory  areas3 
(e.g.,  CopyDIn_local_datain),  2)  to  save  values  in  memory  ar¬ 
eas  as  the  values  of  logical  variables  (e.g.,  CopyDIn_value_data), 
and  3)  to  express  error  conditions  that  the  TLS  implicitly  assumes 
to  be  impossible  (e.g.,  CopyDIn_copy_size_datain). 

After  defining  the  desired  sets  of  code-level  pre-  and  postcondi¬ 
tions,  we  check  whether  these  assertions  are  among  the  assertions 
already  proven  in  the  annotated  C  code.  The  annotated  C  code 
refers  to  memory  areas  by  indexing  into  arrays  that  define  mem¬ 
ory  maps  in  the  code,  whereas  the  mapping  a  refers  to  memory 
areas  by  their  actual  physical  addresses.  Thus,  to  be  equivalent 
to  the  desired  assertions,  the  assertions  in  the  annotated  code  fre¬ 
quently  need  dereferencing.  For  example,  the  annotated  C  code 
assertion  §8.4,  TLS2,  is  defined  by 

3This  facilitates  Floyd-Hoare  reasoning  at  the  code  level. 


part_data_start  = 

(unsignedchar*)ker_rt  ime  jiunujnap  [part  it  ion],  part  _data_st  art, 

which  sets  the  variable  part_data_start  to  the  starting  address 
of  the  data  area  in  the  partition  by  indexing  into  the  real-time  mem¬ 
ory  map  in  the  code  and  selecting  the  part_data_start  member 
of  the  structure  corresponding  to  that  array  element.  Dereferenc¬ 
ing  the  index  into  the  array  and  pointer  into  the  structure  yields  the 
memory  area  KER_PAR_DATA_STORAGE_l_partition_START,  the 
actual  physical  address  of  the  partition  data  area,  which  stores  the 
value  used  in  the  code-level  precondition  CopyDIn_local_datain. 

In  our  initial  attempt  to  match  a  pre-  and  postcondition  in  the 
annotated  C  code  with  each  desired  pre-  and  postcondition,  four 
different  outcomes  were  possible: 

•  The  desired  assertion  exactly  matched  an  assertion  in  the 
annotated  code. 

•  The  desired  assertion  exactly  matched  an  assertion  in  the 
annotated  code  but  dereferencing  was  required. 

•  The  desired  assertion  was  a  close  match  with  an  assertion  in 
the  annotated  code. 

•  No  code  assertion  exactly  or  approximately  matched  the  de¬ 
sired  assertion. 

We  worked  with  the  group  annotating  the  C  code  to  ensure  that  as¬ 
sertions  corresponding  to  all  desired  pre-  and  postconditions  were 
added  to  and  verified  on  the  code.  (In  general,  it  is  sufficient  to 
include  strongest  postconditions  implying  our  derived  assertions.) 
To  show  correspondence  between  the  pre-  and  postconditions  in 
the  code  and  the  TLS.  two  tables  were  created  for  each  TLS  event. 


Table  1.  Mapping  Preconditions  in  the  Code  to  Preconditions  in  the  TLS 


Precondition  <E>(pree)(sc) 
Desired  in  the  Code 

Assertion  in 
Annotated  Code 

Precondition  pree(s) 
in  the  TLS 

Ref. 

No. 

Description 

CopyDIn_partition_id 

§8.4,P5 

cs  =  i 

(1) 

Partition  id  is  i 

CopyDIn_priv 

§8.4,TLS1* 

AM(e,  Bj)  =  R 
AM(e,  Dj)  =  W 

(2) 

R  access  for  Input  Buffer  1, 

W  access  for  Data  Area  1 

CopyDIn_value.dat  a 

§8.4,P4* 

Bis 

- 

Value  of  data  in  Input  Buffer  1 

CopyDIn_def  _value_rest 

§8.4,TLS4 

Dls 

- 

Value  of  Data  Area  1 

CopyDIn_local  .inbuffer 

§8.4,  TLS 3* 

- 

- 

Local  variable  for  Input  Buffer  1 

CopyDIn_local.dat  ain 

§8.4,TLS2* 

- 

- 

Local  variable  for  Data  Area  1 

Table  2.  Mapping  Postconditions  in  the  Code  to  Postconditions  in  the  TLS 


Postcondition  <t>(poste)(sc,  s'c) 

Assertion  in 

Postcondition  poste(s,  s') 

Ref. 

Description 

Desired  in  the  Code 

Annotated  Code 

in  the  TLS 

No. 

CopyDIn_copy_size.dat  ain 

§8.4,R2* 

- 

- 

Wrong  size  — *  Error  return 

CopyDIn.copy.size.inbuf  f  er 

§8.4,  R3* 

- 

- 

Wrong  size  — *  Error  return 

CopyDIn.gamma.copy 

§8.4,  R7* 

Dly  =  r(BD 

(4) 

Copy  to  Data  Area  1 

CopyDIn_gamma_rest 

§8.4,TLS6 

- 

Rem  Data  Area  1  unchged 

CopyDIn.sanitize 

§8.4,TLS5* 

=  false 

(3) 

Data  Area  1  not  sanitized 

CopyDIn_NOC 

By  inspection 

NOC{W^[i],Df} 

(5) 

No  other  change 

Tables  1  and  2  are  the  correspondence  tables  for  the  pre-  and  post¬ 
conditions  for  the  TLS  event  e  =  Copy_Bf rlIn_DatalInJ  de¬ 
fined  in  Section  3.1.  In  the  tables,  s  and  s'  =  T(e,  s)  represent  the 
abstract  pre-  and  poststate;  sc,  and  s'c  represent  the  concrete  pre- 
and  poststate;  and  <f>,  which  is  formally  defined  in  Section  4.  maps 
abstract  predicates  to  corresponding  concrete  predicates. 

In  the  tables,  the  first  column  contains  the  label  of  a  desired 
code-level  pre-  or  postcondition,  the  second  column  gives  the  lo¬ 
cation  (section  number  and  assertion  label)  of  the  corresponding 
assertion  in  the  annotated  C  code,  the  third  column  contains  the 
corresponding  pre-  or  postcondition  (if  any)  in  the  TLS,  the  fourth 
column  gives  the  reference  number  of  the  corresponding  assertion 
in  the  transform  rule,  and  the  fifth  column  briefly  describes  the  as¬ 
sertion.  In  cases  where  no  corresponding  assertion  exists  in  the 
TLS,  appears  in  both  the  third  and  fourth  columns.  An  asterisk 
in  the  second  column  indicates  that,  for  equivalence  between  the 
assertion  in  the  annotated  code  and  the  desired  code  assertion  to 
hold,  the  assertion  in  the  annotated  code  requires  dereferencing. 

4.  Formal  Foundations 

This  section  formalizes  our  method  for  showing  that  the  ker¬ 
nel  code  conforms  to  the  behavior  captured  in  the  TLS.  To  begin, 
a  function  a  is  defined  that  maps  each  concrete  state  at  the  code 
level  to  a  corresponding  abstract  state  in  the  TLS  state  machine  S 
by  relating  variables  at  the  concrete  code  level  to  variables  at  the 
abstract  TLS  level.  Variables  at  the  concrete  level  include  vari¬ 
ables  in  the  code,  predicates  defined  on  the  code,  logical  history 
variables,  and  memory  areas.  Among  the  most  important  memory 
areas  treated  as  concrete  state  variables  are  the  data  areas  and  the 
input  and  output  buffers  assigned  to  each  partition,  which  are  cen¬ 
tral  to  reasoning  about  possible  information  flows.  Because  each 
possible  value  of  a  concrete  state  variable  can  be  represented  by 
some  possible  value  of  the  corresponding  abstract  state  variable, 
the  map  a  from  concrete  to  abstract  state  variables  induces  a  map 
a  :  Sc  —>  S3.  from  concrete  to  abstract  states  in  the  obvious  way.4 

4To  distinguish  abstract  from  concrete  entities,  this  section  tags 
abstract  entities  with  an  a  and  concrete  entities  with  a  c;  for  exam- 


Once  a  is  defined  at  the  level  of  states  in  terms  of  state  variables, 
the  set  Ec  of  Event  Code  code  segments  transferring  data  either 
to  or  from  an  MAI  in  the  current  partition  is  identified,  and  a  is 
extended  to  map  each  code  segment  ec  in  Ec  to  a  corresponding 
internal  event  ea  =  a(ec)  in  the  TLS. 

The  map  a  from  concrete  states  to  abstract  states  provides  a 
means  to  take  any  assertion  Pa  about  abstract  states  and  derive  a 
corresponding  assertion  <f>(Pa)  about  concrete  states  as  follows: 

$(Pa)(sc)  =  Pa(a(sc)), 

where  sc  is  any  state  in  Sc .  Analogously,  a  can  be  used  to  derive 
an  assertion  <f>(Pa)(Sc,  s2)  about  a  pair  of  concrete  states  from  an 
assertion  about  a  pair  of  abstract  states  as  follows: 

$(Pa)(sc1,Sc2)^Pa(a(SJ),a(Sc2)). 

The  map  <f>  is  used  to  relate  preconditions  and  postconditions  in 
the  code  to  preconditions  and  postconditions  in  the  TLS  (see  Fig¬ 
ure  2).  Note  that  preconditions  (at  both  levels)  apply  only  to  one 
state.  To  capture  the  fact  that  an  event  changes  only  certain  state 
variables  (indicated  at  the  abstract  level  using  NOC),  the  postcon¬ 
ditions  are  represented  at  both  levels  as  predicates  on  two  states. 

To  establish  equivalence  between  the  behavior  of  the  kernel 
code  and  a  subset  of  the  behavior  modeled  in  the  TLS,  it  is  suffi¬ 
cient  to  prove,  in  the  simplest  case,  that  for  every  ec  in  Ec, 

1 .  Whenever  the  concrete  code  segment  ec  is  ready  to  execute 
in  state  sc,  some  concrete  precondition  Preec  holds,  where 
Preec  implies  <f>(Preea),  the  concrete  precondition  derived 
from  the  abstract  precondition  for  ea  =  a(ec); 

2.  Whenever  the  concrete  precondition  Preec  holds  for  the  cur¬ 
rent  program  state  sc,  some  concrete  postcondition  Postec 
holds  for  the  pair  of  program  states  (sc,ec(Sc))  immediately 
before  and  immediately  after  execution  of  ec,  where  Poste<. 
implies  <I>(Postea),  the  concrete  postcondition  derived  from 
the  abstract  postcondition  for  ea; 

3.  The  diagram  in  Figure  2  commutes  when  conditions  1  and  2 
are  satisfied  and  Preec(sc)  holds. 

pie,  Sa  represents  the  abstract  states  s  and  Sc  the  concrete  states  s. 


Pree>Oa) 


Postf>(sa,  ea(sj) 


III 

3>(Poste>)(,sc,  ec(sc)) 

IT 

Posla  ( sc ,  ec(sc)) 


Figure  2.  Relation  between  concrete  and  abstract  transitions. 


Provided  Postea(sa,  sa)  =  (sa  =  ea(sa))  (as  holds  forposte  in 
the  TLS  transform  described  in  Section  3.1),  to  establish  condi¬ 
tion  3,  it  is  sufficient  to  prove  that  Preec(sc)  =>  ,l>(Preea)(sc) 
and  that  Postec(sc,  ec(sc))  =>  $(Postea)(sc,  ec(sc))-  Estab¬ 
lishing  conditions  1-  3  guarantees  that  whenever  the  code  segment 
ec  executes  in  the  code,  there  is  an  enabled  event  ea  in  the  TLS  that 
causes  a  transition  from  the  abstract  image  sa  under  a  of  the  con¬ 
crete  prestate  sc  at  the  code  level  into  an  abstract  state  ea(sa)  that 
is  the  abstract  image  under  a  of  the  concrete  poststate  ec(sc)  at  the 
code  level.  More  concisely,  conditions  1,  2,  and  3  imply  that  there 
exists  an  abstract  transition  that  models  the  concrete  transition. 

The  relation  of  Event  Code  segments  to  abstract  events  can  be 
slightly  more  complex  than  shown  in  Figure  2.  For  example,  in 
some  cases,  ec  may  implement  more  than  one  event.  However, 
these  more  complex  cases  can  be  handled  similarly.  When  a  con¬ 
crete  event  implements  n  abstract  events,  for  example,  one  looks 
for  a  partition  Prec  =  Prea  ©  ...  ©  Pre“  of  the  concrete  precon¬ 
dition  Prec  such  that  when  the  ith  part  Prea  holds,  the  code  ec 
implements  the  ith  abstract  event.  Then,  one  establishes  for  each  i 
a  commutative  diagram  analogous  to  the  diagram  in  Figure  2. 

The  argument  that  the  kernel  ensures  data  separation  is  based 
on  relating  executions  of  the  kernel  code  to  executions  in  the  TLS. 
It  begins  by  observing  that  a  maps  ED’s  initial  state  via  a  to  an 
allowed  initial  state  in  the  TLS.  To  support  the  remainder  of  the 
argument,  the  Event  Code  set  Ec  and  the  code-level  map  a  are  ex¬ 
tended  to  cover  the  Other  Code,  and  it  is  shown  that  the  Trusted 
Code  can  be  safely  ignored.  Most  Event  Code  segments  consist 
of  a  single  program  statement.  In  contrast,  Other  Code  contains 
many  lengthy  code  segments  which  simply  manipulate  local  vari¬ 
ables  inside  a  function  or  procedure  and  do  not  map  to  any  abstract 
event;  such  segments  typically  occur  prior  to  an  Event  Code  seg¬ 
ment.  We  model  these  Other  Code  segments  at  the  abstract  level 
by  a  no-op  (“do  nothing”)  event  implicitly  included  in  the  TLS. 

Because  every  code  segment  in  the  Event  or  Other  Code  is 
modeled  either  by  an  abstract  TLS  event  with  concrete  and  ab¬ 
stract  transitions  related  as  in  Figure  2  or  by  a  no-op  in  the  TLS, 
it  follows  that  every  execution  of  this  part  of  the  code  corresponds 
to  an  execution  in  the  TLS.  Because  parts  of  the  Trusted  Code  have 
been  verified  and  the  remaining  parts  have  been  certified  to  cause 
no  insecure  information  flows,  modeling  this  code  at  the  abstract 
level  is  unnecessary.  Combining  this  reasoning  with  the  additional 
assurance  that  a  relates  concrete  data  and  buffer  memory  areas 
to  abstract  ones  and  thus  models  all  information  flows  involving 
Memory  Areas  of  Interest,  it  follows  that  all  kernel  behavior  rel¬ 
evant  to  data  separation  at  the  concrete  level  is  modeled  at  the 
abstract  level.  Thus,  the  Data  Separation  Property  proved  at  the 
abstract  level  also  holds  at  the  concrete  level. 


5.  Lessons  Learned 

5.1  Software  Design  Decisions 

Three  software  design  decisions  were  critical  in  making  code 
verification  feasible.  One  major  decision  was  to  use  a  separation 
kernel,  a  single  software  module  to  mediate  all  memory  accesses. 
A  design  that  distributed  the  checking  of  memory  accesses  would 
have  made  the  task  of  proving  data  separation  much  more  diffi¬ 
cult,  if  not  impossible.  A  second  critical  decision  was  to  keep  the 
software  simple.  For  example,  once  initiated,  data  processing  in 
a  partition  was  run  to  completion  unless  an  exception  occurred. 
In  addition,  ED's  services  were  limited  to  the  essential  ones — the 
temptation  to  add  new  services  late  in  development  was  resisted. 
A  third  critical  decision  was  to  enforce  the  “least  privilege  prin¬ 
ciple.”  For  example,  if  a  process  only  required  read  access  to  a 
memory  area,  the  kernel  only  granted  read,  and  not  write,  access. 

5.2  Top-Level  Specification 

One  major  challenge  was  to  understand  the  required  behavior 
of  the  separation  kernel.  Both  scenarios  and  the  SCR  tools  [19, 
18]  were  useful  in  validating  and  extending  our  understanding  of 
the  kernel  behavior.  To  begin,  we  formulated  several  scenarios, 
i.e.,  sequences  of  input  events  and  how  the  kernel  responded  to 
those  events.  After  specifying  a  state  machine  model  of  the  ker¬ 
nel  in  SCR.  we  ran  the  scenarios  through  the  SCR  simulator.  As 
expected,  formulating  the  scenarios  and  running  them  through  the 
simulator  exposed  gaps  in  our  understanding.  Both  the  scenarios 
and  the  questions  raised  were  valuable  in  eliciting  details  of  the 
required  kernel  behavior  from  ED’s  development  team. 

Keeping  the  size  of  the  TLS  small  was  critical  for  many  rea¬ 
sons.  It  simplified  communicating  with  the  other  stakeholders, 
changing  the  specification  when  the  kernel  behavior  changed,  trans¬ 
lating  the  specification  into  TAME,  and  proving  that  the  TLS  en¬ 
forced  data  separation. 

The  natural  language  representation  of  the  TLS  enabled  stake¬ 
holders  from  differing  backgrounds  and  with  different  objectives — 
the  project  manager,  the  software  developers,  and  the  evaluators — 
to  communicate  easily  with  the  formal  methods  team  about  the 
kernel’s  required  behavior.  Discussion  among  these  various  stake¬ 
holders  helped  ensure  that  misunderstandings  were  avoided  and 
issues  resolved  early  in  the  certification  process.  This  natural  lan¬ 
guage  representation  of  the  TLS  for  ED  contrasts  with  the  repre¬ 
sentations  used  in  many  other  formal  specifications  of  secure  sys¬ 
tems,  which  are  often  expressed  in  specialized  languages  such  as 
ACL2  (see,  e.g,  [17]).  Moreover,  any  ambiguity  inherent  in  the 
natural  language  representation  was  removed  by  translating  the 
TLS  into  TAME,  since  the  state  machine  semantics  underlying 
TAME  is  expressed  as  a  PVS  theory. 


5.3  Mechanized  Verification 

TAME’s  specification  and  proof  support  significantly  simpli¬ 
fied  the  verification  effort.  Translating  the  TLS  into  TAME  re¬ 
quired  about  three  days.  Because  the  number  of  memory  areas  is 
unspecified  in  the  TLS,  the  overall  memory  content  in  the  TLS  had 
to  be  captured  in  TAME  as  a  function  from  a  set  of  memory  areas 
to  storable  values.  The  higher  order  nature  of  PVS,  which  made 
this  feasible,  also  contributed  to  the  compactness  of  the  TAME 
specification,  which  is  only  368  lines  long.  In  translating  the  TLS 
to  TAME,  the  correspondence  between  entities  in  the  natural  lan¬ 
guage  formulation  and  TAME  entities  was  documented.  Adjust¬ 
ing  the  TAME  specification  to  reflect  later  changes  in  the  TLS  re¬ 
quired  less  than  three  hours.  Representing  the  five  subproperties 
in  TAME  required  about  two  hours. 

About  two  weeks  were  needed  to  formally  verify  that  the  TLS 
enforces  data  separation.  Adding  and  proving  a  new  property 
(Kernel  Integrity)  suggested  by  an  evaluator  required  under  one 
hour.  In  proving  the  subproperties,  a  few  days  were  needed  to  for¬ 
mulate  an  efficient  proof  approach.  This  exploration  led  to  a  new 
PVS  strategy  designed  to  simplify  the  proof  guidance  in  the  most 
complex  proof.  This  strategy  was  useful  in  proving  all  five  sub¬ 
properties  and  has  also  been  useful  in  other  TAME  applications. 
The  proof  of  each  subproperty  completes  in  two  minutes  or  less. 
Once  the  correct  proof  approach  was  identified,  the  time  required 
to  develop  the  proof  scripts  interactively  in  TAME  was  one  day. 

5.4  Showing  Code  Conformance 

Two  months  were  required  to  establish  conformance  between 
the  TLS  and  the  annotated  C  code.  In  the  first  month,  we  exper¬ 
imented  with  several  different  approaches  for  demonstrating  con¬ 
formance  before  the  approach  presented  in  this  paper  was  selected. 
Once  an  approach  was  selected,  the  formal  correspondence  argu¬ 
ment  required  one  week.  Three  weeks  were  needed  to  construct 
the  correspondence  of  Event  Code  to  TLS  events,  i.e.,  developing 
the  code  level  assertions  necessary  for  the  TLS  pre-  and  postcon¬ 
ditions  to  hold  and  locating  the  corresponding  assertions  in  the 
annotated  C  code.  One  day  was  spent  using  the  Xcode  tool  to  lo¬ 
cate  all  Event  and  Trusted  Code  and  to  verify  that  the  permissions 
for  the  Other  Code  did  not  include  access  to  MAIs.  One  week  was 
needed  to  add  the  required  assertions  to  the  annotated  code. 

Our  method  for  demonstrating  code  conformance  relies  on  the 
notions  of  MAIs  and  Event  Code.  The  extent  to  which  our  method 
can  be  extended  to  other  applications  depends  on  whether  an  anal¬ 
ogous  method  of  identifying  Event  Code  (and  Trusted  Code)  can 
be  found.  This  is  likely  to  be  possible  in  other  applications  that 
must  enforce  data  separation. 

6.  Open  Problems 

6. 1  Checking  and  Constructing  Code  Annotations 

For  many  years,  researchers  have  recommended  annotating  code 
with  pre-  and  postconditions  and  invariants  (see,  e.g..  [25]).  Code 
annotations  are  already  used  in  practice.  For  example,  software 
developers  at  Praxis  annotate  Spark  programs  with  assertions  and 
use  tools  to  automatically  check  the  validity  of  the  assertions  [10]. 
Moreover,  at  Microsoft,  annotations  are  a  mandated  part  of  the 
software  development  process  in  the  largest  product  groups  [12], 
However,  manual  annotation  of  source  code  with  pre-  and  postcon¬ 
ditions  remains  rare  in  the  wider  software  development  commu¬ 
nity  because  it  is  both  tedious  and  error-prone.  Hence,  automated 


tools  for  checking  code  annotations  would  be  extremely  valuable. 
Even  more  valuable  are  tools  that  can  construct  pre-  and  postcon¬ 
ditions  automatically.  One  approach  may  be  for  a  developer  to 
generate  some  key  pre-  and  postconditions.  Given  a  small  set  of 
annotations,  a  tool  could  then  generate  additional  annotations  au¬ 
tomatically. 

6.2  A  Code  Conformance  Proof  Assistant 

The  semantic  distance  between  the  abstract  TLS  required  for  a 
Common  Criteria  evaluation  and  a  low-level  C  program  is  huge. 
While  the  TLS  describes  the  security-relevant  program  behavior 
in  terms  of  sets,  functions,  and  relations,  the  description  of  the 
behavior  of  a  C  program  is  in  terms  of  low-level  constructs,  such 
as  arrays,  integers,  and  bits  stored  in  registers  and  memory  areas. 
Hence,  automatic  demonstration  of  conformance  of  low  level  C 
code  to  a  TLS  is  unrealistic.  A  more  realistic  goal  is  a  proof  assis¬ 
tant  with  two  inputs,  a  C  program  annotated  with  assertions  and  a 
TLS  of  the  security-relevant  functions  of  that  program,  for  helping 
the  user  establish  that  the  C  program  satisfies  the  TLS. 

6.3  Automatic  Code  Generation 

One  promising  way  to  obtain  high  assurance  that  an  implemen¬ 
tation  satisfies  critical  security  properties  is  to  generate  code  auto¬ 
matically  from  a  specification  that  has  been  proven  to  satisfy  the 
properties.  Automatic  code  generation  is  already  feasible  for  some 
low-level  specification  languages  such  as  Esterel  [1].  While  con¬ 
structing  efficient  source  code  from  more  abstract  specifications 
is  possible  for  simple  program  constructs  using  simple  data  types 
(see,  e.g.,  [30]),  new  research  is  needed  to  produce  efficient  code 
from  specifications  containing  richer  constructs  and  data  types. 
Such  technology  should  drastically  reduce  the  effort  required  to 
produce  efficient  code  and  to  increase  assurance  that  the  code  sat¬ 
isfies  critical  security  properties. 

7.  Related  Work 

In  the  1980s,  the  SCOMP  [13],  SeaView  [22],  LOCK  [35], 
and  Multinet  Gateway  [14]  projects  all  applied  formal  methods 
to  the  specification  and  verification  of  systems.  All  developed 
TLSs  and  formal  statements  of  the  system  security  policies.  For 
SCOMP,  Multinet  Gateway,  and  LOCK,  the  TLS  was  shown  for¬ 
mally  to  satisfy  the  security  policy.  For  SeaView,  only  two  of 
3 1  operations  in  the  TLS  were  verified  against  the  security  policy 
model  [36].  Conformance  between  the  TLS  and  the  SCOMP  code 
was  shown  by  constructing  several  mappings:  English  language 
to  TLS,  TLS  to  pseudo-code,  and  TLS  to  actual  code  [11],  The 
mapping  was  top  down  from  the  TLS  to  code;  as  a  result,  some 
code  was  unmapped.  This  approach  is  similar  to  our  mapping  of 
Event  Code  to  the  TLS.  although  the  mapping  is  in  the  other  direc¬ 
tion.  The  LOCK  project  constructed  mappings  partially  relating 
the  TLS  to  the  source  code;  specification-based  testing  provided 
additional  evidence  of  correspondence.  In  Multinet  Gateway,  ver¬ 
ification  conditions  were  generated  to  show  conformance  between 
the  specification  and  the  code.  If  and  how  these  conditions  were 
discharged  is  unclear.  Each  project  used  tools  to  aid  in  specifi¬ 
cation  and  verification:  SCOMP  used  HDM  [29],  Seaview  used 
EHDM  [32],  and  Multinet  Gateway  and  LOCK  used  Gypsy  [15], 
More  recently,  in  2006.  we  formulated  a  second  possible  approach 
to  software  verification,  based  on  TAME,  which  uses  verified  for¬ 
mal  pseudocode  as  “glue”  relating  a  TLS  to  actual  code  [9]. 


In  [17,  5],  Greve,  Wilding,  and  Vanfleet  (GWV)  present  an 
ACL2  model  for  a  generic  separation  kernel.  In  the  model,  a  func¬ 
tion  describes  the  possible  information  flows  between  memory  ar¬ 
eas.  This  notion  of  flow  is  not  as  fine-grained  as  in  our  model, 
where  access  (with  its  possible  information  flows)  is  granted  to 
each  process  only  when  it  executes  in  a  partition,  thus  provid¬ 
ing  least  privilege  in  addition  to  separation.  In  the  GWV  ap¬ 
proach,  separation  includes  No-Exfiltration  and  No-Infiltration  but 
not  Temporal  Separation,  since  the  model  does  not  allow  recon- 
figurable  partitions.  How  the  GWV  model  was  used  to  verify  the 
AAMP7  microprocessor  is  described  in  [16,  28],  A  traditional  ver¬ 
ification  process  was  followed:  build  a  formal  security  policy,  an 
abstract  and  detailed  model,  and  an  implementation;  prove  that  the 
abstract  model  satisfies  the  security  policy;  and  show  correspon¬ 
dence  between  the  abstract  and  detailed  models  and  between  the 
detailed  model  and  the  implementation.  Whether  correctness  was 
proven  at  either  the  detailed  design  level  or  code  level  is  unclear. 

8.  Conclusions 

This  paper  has  introduced  a  novel  and  affordable  approach  for 
verifying  security  down  to  the  source  code  level.  The  approach  be¬ 
gins  with  a  well-defined  security  policy,  builds  the  minimal  state 
machine  model  needed  to  prove  that  the  model  satisfies  the  policy, 
and  proves,  using  a  mechanical  verifier,  that  the  security  model 
satisfies  the  policy.  Once  complete,  the  code  is  annotated  with 
preconditions  and  postconditions  and  then  partitioned  into  Event, 
Trusted,  and  Other  Code.  The  final  step  is  to  1)  demonstrate  con¬ 
formance  of  the  Event  Code  and  the  code  pre-  and  postconditions 
with  the  internal  events  and  pre-  and  postconditions  of  the  TLS 
and  2)  show  that  the  Trusted  Code  and  the  Other  Code  are  benign. 

Tools  such  as  model  checkers  and  theorem  provers  are  already 
available  for  verifying  that  a  formal  specification  satisfies  a  secu¬ 
rity  policy.  A  research  challenge  is  to  develop  tools  1)  for  vali¬ 
dating  and  constructing  pre-  and  postconditions  from  source  code, 
including  C  code,  2)  to  help  show  conformance  of  annotated  code 
with  a  TLS,  and  3)  to  automatically  construct  efficient,  provably 
correct  code  front  specifications.  Research  that  addresses  these 
three  problems  should  significantly  increase  the  affordability  of 
constructing  verified  security-critical  software. 
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